Software developers face the fundamental problem that writing an enterprise-wide application is difficult, and writing a distributed application is even more difficult. In addition, an enterprise seeks to build an application as fast as possible without being locked into one platform. Ideally, enterprise developers would like to be able to write the application once and run it on all of their platforms. Enterprise JavaBeans technology seeks to provide this ability.
The Enterprise JavaBeans (EJB) component architecture is designed to enable enterprises to build scalable, secure, multi-platform, business-critical applications as reusable, server-side components. Its purpose is to solve the enterprise problems by allowing the enterprise developer to focus only on writing business logic. The EJB specification creates an infrastructure that takes care of the system-level programming, such as transactions, security, threading, naming, object-life cycle, resource pooling, remote access, and persistence. EJB also simplifies access to existing applications, and provides a uniform application development model for tool creation use using object-oriented programming techniques.
Object-oriented programming techniques involve the definition, creation, use, and instruction of “objects”. These objects are software entities comprising data elements or attributes and methods, which manipulate data elements. Objects also may include data related to events outside of the object to trigger or control methods within the object.
Java is an object-oriented programming language and environment focusing on defining data as objects and the methods that may be applied to those objects. Java supports only a single inheritance, meaning that each class can inherit from only one other class at any given time. Java also allows for the creation of totally abstract classes known as interfaces, which allow the defining of methods that may be shared with several classes without regard for how other classes are handling the methods.
The Java virtual machine (JVM) is a virtual computer component that resides in memory. In some cases, the JVM may be implemented in a processor. The JVM allows Java programs to be executed on a different platform as opposed to only the one platform for which the code was compiled. Java programs are compiled for the JVM. In this manner, Java is able to support applications for many types of data processing systems, which may contain a variety of central processing units and operating systems architectures.
To enable a Java application to execute on different types of data processing systems, a compiler typically generates an architecture-neutral file format—the compiled code is executable on many processors, given the presence of the Java run-time system. The Java compiler generates bytecode instructions that are non-specific to a particular computer architecture. These bytecodes are executed by a Java interpreter. A Java interpreter is a module in the JVM that alternately decodes and executes a bytecode or bytecodes.
A Java bean is a reusable component. Various programs in Java may be created by aggregating different Java beans. An entity bean represents a business object in a persistent storage mechanism. Some examples of business objects are customers, orders, and products. In the J2EE (Java 2 Platform Enterprise Edition) SDK (Software Development Kit), the persistent storage mechanism is a relational database. Typically, each entity bean has an underlying table in a relational database, and each instance of the bean corresponds to a row in that table.
Entity beans differ from session beans in several ways. Entity beans are persistent, allow shared access, have primary keys, and may participate in relationships with other entity beans. Because the state of an entity bean is saved in a storage mechanism, it is persistent. Persistence means that the entity bean's state exists beyond the lifetime of the application or the J2EE server process. The data in a database is persistent because it still exists even if the database server or the applications it services are powered off.
There are two types of persistence for entity beans: bean-managed and container-managed. With bean-managed persistence, the entity bean code contains the calls that access the database. If a bean has container-managed persistence, the EJB container automatically generates the necessary database access calls. The code for the entity bean does not include these calls.
Entity beans may be shared by multiple clients. Because the clients might want to change the same data, it's important that entity beans work within transactions. Typically, the EJB container provides transaction management. In this case, the bean's deployment descriptor specifies the transaction attributes. Transaction boundaries are not coded in the bean because the container marks the boundaries.
Like a table in a relational database, an entity bean may be related to other entity beans. For example, in a college enrollment application, StudentEJB and CourseEJB would be related because students enroll in classes.
Developers implement relationships differently for entity beans with bean-managed persistence and those with container-managed persistence. With bean-managed persistence, the code implements the relationships. But, with container-managed persistence, the EJB container takes care of the relationships for the developer. For this reason, relationships in entity beans with container-managed persistence are often referred to as container-managed relationships.
The term container-managed persistence means that the EJB container handles all database access required by the entity bean. The bean's code contains no database access calls. As a result, the bean's code is not tied to a specific persistent storage mechanism (database). Because of this flexibility, even if the developer redeploys the same entity bean on different J2EE servers that use different databases, modifying or recompiling the bean's code is not necessary. In short, container-managed persistent entity beans are more portable.
Besides being much easier to develop and offering greater portability, container-managed persistent beans have additional benefits over bean-managed persistent beans, such as query, caching, and connection pooling. Also, container-managed persistent beans enable greater configuration and administration options, allowing dynamic control over access intent and connectivity parameters.
The EJB specification defines the concept of a deployment descriptor, which is stored in XML (Extensible Markup Language), which essentially contains information used during deployment of the bean to an application server. It also defines multiple roles involved in the process of creating and deploying an EJB-based application, including the bean developer, the application assembler, and the deployer. The bean developer is the one who actually writes the Java code for the EJB. The application assembler is the one who fills out the deployment descriptor, helping map the general purpose bean to a specific use, such as the specifics for the persistence of the bean, such as describing the mapping of a CMP (container managed persistence) bean to a table in a particular database vendor's database. The deployer is the one who uses the information from the deployment descriptor to generate the necessary artifacts to run the bean on a specific application server.
There are two types of deployment descriptors: generic and vendor-specific extensions. The generic one (named ejb-jar.xml), whose schema is defined by the EJB specification, and which all application server vendors must support, contains basic structural information about the bean, such as a list of the CMP fields and the key class for a given CMP bean. The deployment descriptor extensions, which are specific to a given application server vendor, contain specialized deployment information not formalized or required by the EJB specification, such as settings used by a value-added proprietary service implemented by a specific vendor. As the EJB specification evolves from version to version, the contents of the generic EJB deployment descriptor continue to expand, as vendors bring forward some of their extensions for standardization as part of upcoming versions of the EJB specification, via the Java Specification Request (JSR) process.
Unfortunately, container-managed persistent beans are only able to access relational databases. But, many users want the convenience of using container-managed persistent beans, but their data is stored in a non-relational format. Without a way for beans to access non-relational data, many users will be unable to take advantage of the convenience of the container-managed persistence.